The first computers were largely stationary units that operated on fixed power. Early multitasking solutions focused mainly on maximizing CPU utilization and computing task throughput. Over time, computers became interactive. For example, time-sharing computers were developed that allowed multiple users to interact with the same computer at the same time with the perception to each user that he or she was the only one using the computer.
Today, many computers are preemptive multitasking systems. In many preemptive multitasking systems, an operating system determines when and for how long each of multiple applications execute. Developing applications for most preemptive multitasking systems is a relatively simple in the respect that such applications do not need to be programmed to voluntarily cede CPU time to allow other applications to execute. Instead, the operating system interrupts executing applications as and when efficient or convenient to do so to allow other applications to have CPU time.
At the same time, as more and more portable computing devices operate on battery power and with relatively limited computing resources (e.g., memory), some operating systems on portable computing devices perform a form of preemptive multitasking of applications to limit computer memory usage, conserve battery power, and increase the time between battery charges. In particular, some operating systems allow only one application or only a small number of applications to actively execute in the “foreground” at a time. In many cases, these operating systems allow only the foreground applications to receive and respond to certain user interface events. These operating systems may place a current foreground application into the “background” to allow other applications to execute as a foreground application. To limit computer memory usage and conserve battery power, these operating systems may allow a background application to perform only limited computation or not perform any computation at all. Further, these operating systems may not allow or may provide only limited ability for a background application to programmatically foreground itself when in a background state. Instead, a background application is forced to rely on the operating system to bring it into the foreground at the appropriate time, for example, in response to user input detected by the operating system.
To limit computer memory usage and conserve battery power, an operating system on a battery-operated portable computing device will often maintain an executing application in one of a set of possible application execution states. A typical set of application execution states is shown in FIG. 1, wherein the application execution state diagram 110 includes a “not running” state 112, a “foreground” state 114, and a “background” state 116. In the not running state 112, the application has not been launched or was executing but has since been terminated by the operating system. When an application is launched, the operating system transitions the application from the not running state 112 to the foreground state 114. In the foreground state 114, the application is executing in the foreground and typically can receive and respond to certain user input events such as, for example, touch screen input events. Various system events can cause the operating system to transition an application from the foreground state 114 to the background state 116. For example, the operating system may transition an application currently in the foreground state 114 to the background state 116 when a user presses a “home” button of the device or when another application is launched. As mentioned above, the operating system may prevent an application in the background state 116 from executing any tasks or may allow the application to perform only certain limited “background” tasks such as, for example, playing audible content, downloading a file from a network service, or communicating with an external accessory (e.g., a Bluetooth peripheral). The operating system may transition the application from the background state 116 back to the foreground state 114 in response to detecting certain system events such as, for example, a user re-launching the application. In some situations, the operating system may transition an application in the background state 116 to the not running state 112. For example, the operating system may transition an application in the background state 116 to the not running state 112 to free computing resources (e.g., memory) for use by current foreground applications or if the application has been in the background state 116 for longer than a predetermined amount of time.
Overall, by design, operating systems on some types of portable battery-operated computing devices largely, if not exclusively, control when an application transitions from the background state 114 to the foreground state 112. This lack of control by background applications to trigger the transition on their own presents a challenge to a developer of an application for such an operating system. In particular, the developer may wish to automate the testing of certain application features that are invoked when the application transitions from the background state 114 to the foreground state 112. Since there is typically no programmatic way within an application to by itself force such an operating system to transition the application from the background state 114 to the foreground state 112, the transition cannot be automated from within the application. In some cases, the transition may be triggered manually by a user. However, such manual triggering is a less than ideal solution where automation is preferred.
A testing solution is desired that controls background applications to provide automated testing. The solution should not only address the problem of automating the transition of an application from a background state to the foreground state, but should also provide a solution to the more general problem of controlling application state transitions for automated testing purposes. The present invention provides a solution for these and other needs.
The approaches described in this section are approaches that could be pursued, but not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated, it should not be assumed that any of the approaches described in this section qualify as prior art merely by virtue of their inclusion in this section.